I've begun work on a AWT Toolkit implemented with SwingWT. It is progressing nicely. It can now display simple swing applications. It also handles the mouse events from these applications.

SwingWT Screenshots

The code is now in swingwt's cvs. It should show up in the public cvs shortly.
Once it does you can check it out at:
cvs.sourceforge.net:/cvsroot/swingwt
you'll need the AWTonSWT module and SwingWT module

AWTonSWT Directions

Current Tasks

• popups don't draw at first and flicker
• mutiple graphics pointing at one offscreen image
  works but requires patch to swingwt
• double buffering is slow - this is currently disabled by having createImage on ComponentPeer return null.
• image alignment - swt advanced graphics is shifting images when they are drawn. If interpolation is not set to low then they show up blurry. If it set to low they are shift one pixel down and right. I think some of the graphics artifacts I'm seeing are related to this.
• clipping - it seems the graphics isn't getting clipped quite right.
• test embedding in eclipse

• fonts - they are at least drawn in the correct place now, but I don't know if styles and sizes are supported correctly.

• BufferedImage handling isn't correct. Using Sun's graphics2d is the easy way to support drawing on BufferedImages, but that seems not feasible on OSX. So the alternative is to use swt to draw to a intermediate image and copy that to the BufferedImage. The problem is figuring out how often to copy the data over, and dealing with times when programs modify the content of the buffered image directly while they are drawing on it with an swt graphics.

• profile swt resource disposal

• use code generation to elimnate the need for proxy objects. Currently there are proxy objects that allow java.awt objects to be passed to swingwt.awt objects and vice-versa

Test Goals

• run Squiggle Browser - batik svg browser, it runs, but the file dialog doesn't work,
  and the toolbar uses gray filtering which requires image source and producers to work.
• run JGraphPad - has internal frames, and makes testing graphics2d possible
• run NetBeans embedded in Eclipse on OSX - this will be a great demo

Usefulness

This is useful for several reasons.

• It provides a good way to test the low level swingwt drawing and event code. Running an application with the SWTToolkit and with the standard Sun toolkit makes it easy to compare their look and behavior.
  • Events - because this code is being used to turn swt events into awt events, those events needs to be nearly perfect so Suns swing classes work correctly.
  • Graphics - suns swing classes use many features of the graphics environment: volatile image, multiple graphics objects, paths, ... so these things need to work correctly otherwise you can see problems.
• It should make it possible to embbed swing components inside of eclipse on osx.
• I believe there is a swt implemention for linux framebuffers. So this would allow swing applications to run ontop of framebuffers instead of X11.
• Complicated swing components like HTMLEditor kit will be difficult to get right in SwingWT. Providing similar functionality is already there, but supporting applications that have extended HTMLEditor kit will be difficult. The number of these applications is probably small, but I have one I've written I'd like to see work. And a co-worker has another.